Hi,

I have a Step sequencer I made using toggle boxes. I store the presets in text files. I actually like this system, but when I switch presets there is a little glitch often times.

Most of the time I use my step sequencer on a Rpi 3, so cpu is a concern. I also use my step sequencer to store drum beats, where many voices might have a hit in the same beat, like a hi hat an a kick drum, or a hi hat and a snare drum.

It has been recommended to me to make a sequencer using an array, and storing presets in tables. But I can't seem to figure out how you can have multiple values in a column in an array or table. Seems like you can only have a monophonic type sequence.

I also can't figure out how to quantize an array or table to a integers. if one percussion instrument is value 1 an another is 2 I really don't want values like 1.5 or 1.2. So how do I quantize values?

If any one has thoughts on this please let me know. Should I be looking at other methods instead of tables and arrays? Or if anyone has an example patch I can look at please post a link.

Thank You.

@nicnut I was suggesting 1 (64-step) array for all voices, just to be clear..
then instead of storing 8X64=512 floats for each pattern you would only have to store 64 floats, and only need 1 text file per pattern. But if you want to save patterns per-voice this might not be the best, and idk if it would be better or worse for cpu when loading, or how much extra ram the necessary objects would take.

here https://github.com/sebshader/shadylib
I have abstractions called seqbank and mseq that store 16-step sequences in arrays, though they store floats, not binary values. maybe they would be helpful to look at..

for cpu speed in playback, arrays for each voice probably will be best. you'd have 8 simple reads per step rather than 1 read and a buncha bit-shifting shenanigans, which in pd involves a lot of unnecessary float-int casting and calls. (tho ram usage might be lower with a few objects vs. 7 arrays of 64 floats)

edit: I forgot there's also [tseq] in the GitHub repo which might be similar to what you want (stores toggle values to an array), though it leaves state saving up to the outside world (a crude example of that is in tseq-help.pd). Anyways you could just use the read/write method for array if you want to save per-voice, that'd be easiest.

you could still use the binary trick for state saving though (files would be smaller, not sure if it would be slower or faster loading)

if you are interested in that, to elaborate: say hihat is at bit position 0 and snare is at bit position 1. Then if you wanted the first beat with just snare and the second with both you'd have the first value of the file as 2 and the second as 3 (because the bit values would be 10 for snare on & hihat off, which is 2 in binary, and 11 for both on, which would be 3 in binary. Then in your preset loader, for each step in the sequencer you loop through each bit of that number using a [>> 1] object with a loop and store that value in the appropriate toggle & array for the correct voice and step # using [& 1])

edit 2: I'm not actually sure if pd is capable of saving all 24 bits.. might only work up to 18 bits or something. But it can definitely do 8 bits at least

toggle_seq.zip

@seb_harmonik.ar Thanks for the link to your github folder. Wow, a lot of great stuff in there!

I looked at your sequencers, mseq and tseq, and of course I love that your sequence is written into an array. I posted a version of my sequencer for comparison, and they seem similar in some ways. For mine to work you need a folder called dseq in the folder of the sequencer and that's where text files will be written when a preset is stored. And I have space to save lots of presets.

In yours, it looks like when you hit the "store " button the sequence goes into a message box, and each track has it's own message box and arrays.

So let's say in your method, using arrays, I have 40 presets. Should I save each one to a message box, for each track. Then when I want to recall that track I send a message to all those message boxes and they send the info to their associated arrays? What would be the best way to take your concept of using arrays from tseq or mseq and build it out into an 8 or 16 track 64 step sequencer? That's what I'm trying to get at.

I think the method of using bits to store everything from every track into one huge array might take me a long time to figure out, so saving each track to a different array seems more appealing to me for now.

Thanks again for the input.

@nicnut message boxes are the best way to save presets in the patch instead of in external files, so imo it's not even necessary to use them in your case.

I would just have an array for each drum's sequence that mirrors the value of the toggles. Every time a toggle is changed, write to the array in the right location for that step. For loading, load how you have been (by sending to the toggles). For saving, all you have to do is send for instance the message [write dseq/$1-seqd3.txt( to the array for that drum. (like [s drum3] if "drum3" is the name of the array)
Then when the sequence is being played instead of the giant select all you need is e.g. [tabread drum3] for each drum

btw, another option is to use the tglgrid external https://github.com/nicklan/tglgrid. You'd have to have a route after the [tglgrid] that routes depending on if you're saving or playing.

seqComposite1.zip

@seb_harmonik.ar I'm trying to composite ideas from my sequencer and yours to make use of arrays. The things from mine are just the saving and recalling of presets, but it's getting a little confusing.

I renamed your tseq abstraction to tnseq. One thing that hanging me up is to send unique data from each tnseq object. So I tried [send $0-row] but that doesn't work. I can't figure out why. I figure if I have 8 rows (maybe more) each rows needs to have data sent and stored in a different place.

In the "storing presets" box, I want to have a different pd object for each row. What I am trying to do is compile each row's information into a message box with the preset number, the row number and the toggle box information. I was going to then store each preset (there might be 100) into a different array. Is this a crazy way to go about that? I can't really conceive of any other way to go about it.

If anyone has some improvements or suggestions please let me know. Thank you for all the help!

@nicnut this is the kind of thing I had In mind. each abstraction has the argument $0-drum1, $0-drum2, etc. (open 64seq, then you'd play your sample whenever the # out of [r $0-drumx-val] is 1)

edit: reupload, the [sel 63] in the counter should have been [sel 64]
64seq.zip

@seb-harmonik.ar said:

btw, another option is to use the tglgrid external https://github.com/nicklan/tglgrid. You'd have to have a route after the [tglgrid] that routes depending on if you're saving or playing.

That looks interesting, is there a binary available for OSX?
I can't find it on Github or Deken.

tglgrid.zip @dom1817

@nicnut There was an object [iem_pbank_csv] that I used all the time for presets.
It stores and recalls a set number of lines of a set length... and can write them out to files that can be read back in.
So much like the new [text] object.
So I made, following fairly closely an object [pbank]

Moonlib's shared list [slist] was also useful for such things.
Because one can only have one array defined for a specific name I had to have an [slist-master] and an [slist] to use elsewhere.
The original was for symbols.... and I can't remember if mine will work for floats......
Both made using [text].......... stuff.zip
The [iem_pbank_csv-help] is from the original but should apply to [pbank]
David.

@seb-harmonik.ar
THANKS

thanks everyone for your comments. i've sort of been preoccupied by armageddon happening around me here in LA this week. I'm getting back into this sequencer now. @seb-harmonik-ar this 64 step sequencer is beautiful. Im going to try and wrap my head around this more before I comment or ask more questions. Thanks for posting this.

I looked at 64seq patch which is really cool. It looks like is saves the sequencing presets to text files. I realize that there are also arrays involved inside each row.

So, in this method will there still be glitches or not? I was thinking I needed a system that didn't use text files at all, and only saved every preset to a bunch of stored message boxes or arrays. I guess it's possible if the toggle boxes are reading from tables or arrays the glitchyness might not be there. Is that they case or should i continue to try and develop something that doesn't use text files at all?

Thanks, Nick

@nicnut storing the patterns in memory will probably take more ram but definitely less load time when changing patterns
I guess the best way is to use [array define -k] if you don't need to store an infinite # of possible patterns. Here's a version with arrays for up to 64 patterns (64 patterns X 64 steps = 4096 steps for each [array define])

64seq-arrays.zip

In this version, every time you click a toggle it will save that value in the array (so there is no "reloading the current pattern" and all edits are destructive, in order to do reloadable current patterns you might want to have a current-pattern array or position in the global array that you copy the current pattern into, so when you want to reload the pattern you could just re-copy it)

@seb-harmonik.ar ok this looks good. I'm gonna examine this one and let you know what I come up with. Thank you so much for the input and help!

Hey @seb-harmonik.ar and anyone else following this thread.
Just wanted to update you. I found a way way easier way to have a drum sequencer, store beat patterns, etc.

In the else library there is an object called drum.seq. Wow. it just made my life a lot easier. I think its pretty amazing does what I've been trying to figure out here with barely any objects and no text files.

Thank you everyone for the help with this issue!