posted this on the fb group as well but curious as to what answers I'd get here:

how do you deal with scheduling/sequencing multi-parameter note events? say something like pitch, amp, dur, panning for each note? do you use one list with n-elt chunks dealing with n parameters? n different arrays/lists? [text sequence]? structs? manage to compile xeq and make sense of it? How do you deal with unit changes (switching from 16ths to say 8th note qunituplets)? In Pd, I've never really felt comfy with working with these sorts of things

in the past, i've used an absttraction I made based off the list sequencing example except with multiple parameters (found here ) and it gets feeling a little unwieldly/unstructured with a larger number of parameters or longer sequences and it's at those times I start wishing for multidim arrays or nested structures like lists in lists or jsony sorts of things (which I suppose text/structs kinda do), something make dealing with the whole thing a little bit easier. Lately I've also been experimenting with embedding info in just one number,.. so like 3.54 where 3 is the pitch from an array, 0.5 means it's twice as fast, 0.04 means it's panned left (making 0.06 panning right, 0.05 center pan). also a bit unwiedly and kinda confusing

@dxk Personally, I've never tried building something like that but if I did I'd be most certainly using [text] in one way or another. The examples in the help file for [text sequence] show the basics of how to go about it. There is also [qlist], but I think it's less versatile.

@weightless Yeah, I've used [qlist] in the past for sonification stuff. the issues i have with [text sequence] and [qlist] is that there's basically one send symbol binding per line, and the primary way of jumping back and forth through the text (say to jump from note 5 to note 1 to note 16) is through line numbers and that requires some bookkeeping. A way around that is to put in flags before every parameter chunk (say like a line with just "note2" or something) but then to get to "note100" you have to [text search] through the entire thing to hit "note100" (at least per my guessings as to how [text search] works, haven't combed through the source too thoroughly)

If you know the number of dimensions, i guess one array with n-tel chunks or one array for each dimension would be the fastest. At least [text get] seemed to be slower in the one occasion i tested it.

Maybe speed isn't everything. [text] is much more convenient than [array] or [list store].

i made this three demo sequencers, each with one of [text], [array] or [list store]. They all do the same, play on bang or number, store on list and be reset by the right inlet:

seq-demo.zip (updated)

First of all, [text] doesn't need to know the width of a line. It is possible to mix different lengths. [text] also needs the fewest code. The array sequencer has a major flaw: Because it cannot be set to zero size, it still sends out zeros when it is played but should be reset.

So i think, [text] is actually great for sequencing.

There where some major bugs, they should work now.

@dxk Yes, with [text sequence] you could start each line with a "note_n" flag and use the -w argument to set a flag for waits. To jump to a particular note you can connect the output of [text search] thus:

[note_16(
|
[text search $0-sequencer 0] -> 0 means search in the first field of each line
|
[line $1(
|
[text sequence $0-sequencer]

Like I said, I haven't tried it yet and I'm sure it would require some trial and error (as well as some trickery) to get it to do what you want, but I'd say in general [text] is a lot more flexible than both lists and arrays (even if you don't use [text sequence] and build a sequencer around [text get]). It's also easier to save, read and modify the sequences "by hand" this way.

i made some condensed versions of the above, now all sequencers act the same, the array and list sequencers support variable value length as well. They use an additional index array/list to keep track of position and length. Still, the text sequencer is far cleaner and more straightforward than the othes.

seq-demo.zip

@weightless Yes I mentioned issues with the [text sequence] and its linear search and with a non-neglible length of text, you start getting dropouts and non-negligible search times

@ingox cool, thanks for the tests. I suppose that's one way of looking at it with one line per note event then unpacking and manually doing the sends, which isn't the worst thing in the world. And then maybe breaking it up into several [text]s for subsections or diff groups. I suppose I just a little too attached to the idea of having structured key/value data that doesn't rely on linear search ala JSON and liking working in Pd but missing the power of SuperCollider patterns where it's basically OSC bundle format with typetags and such like \duration, Pseq([0.25, 0.5], inf]), \pan, Pseq([-1, 0, 1, 0.5], inf) and such. I guess the closest thing in Pd right now is structs? but even then you still face the issues with linear search. I guess I'll have to try to think more Pd-like for now =)