@source audio -- Thank you so much; this is magnificent. <3 May I ask how long have you've been at this? Just curious, as I've seen and admired quite a few of your contributions to the forum over the past year or so.

coll is my favorite when it gets to storing lists. Did not cost much time, because I used similar things before, not necessary for matrixctrl but for similar things, like sorting held midi notes for example adapting that to your example was than not too difficult

Re: coll - I'd tried using it previously but ran into a snag when sending coordinates as a symbol through [prepend store]. I now see the "$1 -" message was the solution to that. Nice. :)

Now, I find myself wondering how to get this working when using dial mode. I like how you have coll sorting coordinates, but I doubt that would work with dial mode. Hmm.

To elaborate on my intended use case for this, I plan to: 1. send each list through a [vexpr]. 2. reunite the result of each. (via [zl.lace]) 3. append the 1 (or greater) for each active cell. (with [zl.stream 2] > [pack l i]) 4. generate inactive cell values for the new dimension, to avoid using a clear message. 5. feed the processed list into a second [matrixctrl].

4** -- The next hurdle will be figuring out how to generate inactive cell values, rather than preceding the adjusted list with a clear message. (In previous attempts, the clear message in-between each adjustment produced a lot of extraneous data, making it hard to reliably pull data from.)

Sincerely, Aaron

You should have started with that dial mode if that was the goal. Not doing so is just waste of time... in dial mode there is no empty cell, just a value that could be > 0 or not Maybe you should rethink the whole concept. Why use matrixctl at all ?

Re: Why use [matrixctrl] at all? - It was due to how much I'd found myself using it. Both [router] and [matrix~] are built to interface with it; Gregory Taylor's Step by Step book used it a fair amount. For sequencing, I know several to have used and advocated for [multislider], though reducing a [matrixctrl] to one row in dial-mode achieves the same result, so does it not provide more overhead than [multislider]? I know Jean mentioned [jit.pwindow] as a potential workaround a bit ago, but after doing a bit of experimenting, I agreed that it wasn't worth it from a UI experience, standpoint. What other alternatives are there? Re: My reasoning for not having led with dial-mode: - I was more so focused on the collection of the X/ Y axes, as those are the collections I want most to process. I'm sorry for not having stated a concern for the Z axis upfront; I'm not trying to waste anyone's time. =/ Sincerely, Aaron

Sorry, I did not mean my time wasted, but your time... And for me it is perfectly all right whatever you want to use, it is just that looking from outside, and not knowing the context of the whole construct, one asks such questions. I still don't know what you are after, but generally - matrixctrl is allways having all rows and columns occupied by a value, being a zero , 1 or a value from dial. If you want to manipulate only cells that are > than zero that is not a problem, and is fast enough. You modify the values at same addresses. more efficient than having to clear the matrix and then send all "populated" values I'd think would be to allways send the full list.

Ok, so the primary objective (among others) is resampling cell states to another resolution. The construct is: 1. the reference [matrixctrl #1] 2. the processor [what I've been building] 3. the result [matrixctrl #2] The problem with "always send the full list" is that, when changing the resolution, the length (of the full list) expected by the second matrix will be different from the length (of the full list) issued by the first. My first attempt was to use jit.matrix to do the resampling, but active cells would be repeated when upsampling. My second attempt was to simply bang the first matrix (reference) to send the full list, and filter out the inactive cells, process, and clear the second matrix before issuing every new active cell state, but that creates a lot of extraneous data that makes it difficult to work with. So my current thought process is: Surely, there's away to generate inactive cell values around the processed active values, before sending to the second, bypassing the need for a clear message. Sincerely, Aaron

I don't really get that process between 2 matrixctl objects, but there should be no difference between switch and dial mode in the patch below in addition to cell coordinates as symbol also x y and data of any > 0 cell is stored into coll. You can use that to separately group, scale, repack or whatever and send somewhere else, like matrixctl B. I assume that both matrixctl A & B are having same number of rows and columns. in case of 8x4 it is only list of 96 items. easy to deal with

Re: ^this patch:

Oh, ok nice. :) So you could then not worry about the second output of coll > [fromsymbol] > [unpack 0 0] and just use an [unpack 0 0 0] into 3 [zl.groups] out of the first coll output, then? :) -- I like that a lot; that makes a ton of sense. I went ahead and made ^that adjustment, while swapping [if] with [routepass 0]. Was there a purpose [capture] was serving? This is actually the first I'm seeing that object.

"I assume that both matrixctl A & B are having same number of rows and columns."

They are not. What I meant by upsampling/ downsampling resolution was "to change the row/ column counts, while retaining the same image". So when you increase/ decrease the number of cells in [matrixctrl b], you either need to create inactive cell values to add to the list of processed active cell values (the next step), or clear [matrixctrl b] before populating with active values.

As of this moment, the only purpose [matrixctrl a] serves is to provide the list to process to send to [matrixctrl b]. If you could dump A's cell state into a list, you could potentially remove the need for A. (Though, the notion of daisy-chaining, once removing the need for a clear message, is a fun one.) Sincerely, Aaron

capture was left in without need, forgot to delete it... I sometime use it to collect raw data. I wish you to get that working the way you want

Ah, I see. Duly noted. :) Thank you so much. EDIT: Ok, so after a bit of head scratching, I managed to locate this thread, and Bas's solution seems to be doing the trick. If anyone happens to pop in and know of a slicker method, please do tell. 🙂

Aaron

Ok, so I now have two lists that I'm attempting to merge: - The format is in [matrixctrl]'s "x y z". - The first list contains select active pairs: "x y 1". - The second list contains all possible inactive pairs: "x y 0". I'd like to look for the duplicate "x y" pairs in each and remove those with a 0/ keeping those with a 1. (Sorting isn't a concern, atm.) Sincerely, Aaron

here is list merger and slicker empty list creator...

Sorry for the delay, man. I'll give these a glance and respond, shortly. Currently wrapping up mastering work for a client. 😅 Really, though. Thanks for your time/ effort assisting. <3