This may sound confusing, if so no worries.

OK... right now I'm working with 4 voices, each with 5 values that I want to be able to occasionally sweep (fund freq, vibrato range & speed, tremolo level & speed). I don't have a piano keyboard, and may never get one because I prefer to send ordered, pre-loaded lists of notes and envelopes to the instruments to control their sounds, rather than MIDI device inputs. I'm wondering if there's an easier way to program sweep information than the method I'm building now (which is to store each upcoming sweep as it's own pre-loaded table of offest values, and have each list of tables accessed by sending the address referencing the voice-modifier I wish to sweep). That way I can encode the ranges, direction changes, and speeds of a particular sweep motion with a single, easily-resized data structure.

Basically when I want a certain input to a particular voice swept, I just negate the value I'm sending (since they are all otherwise positive), then use a cell logic to return the abs values to the voice player, and if negative then also send a message to my sweep sequencer consisting of "addresses", which are just numbers representing which voice's modifers I want swept on the current beat. The sweep sequencer then decodes this address using a large [select] to choose which of 20 lists of sweep-offset-tables to use: (to tabread through @ 1 index/ms, then send & add the sweep-offset values to the proper modifier input of my voice player, and finally, prime the next offsets table to use next time the same address is sent to the sweep sequencer.

This means that my little 4-voice synth, with 5 sweepable modifiers per voice, will require 20 separate lists of tables (I figure anywhere from 0-30 tables per list in a given track). To me this seems like kind of an ugly/expensive approach, but it's alot faster than the only other programmable-sweeps method I could come up with.

I bet this post looks like a train wreck, but hopefully someone else has "been there" and can visualize what I'm trying to do. Is this going to be the easiest way for sending programmed sweeps? Maybe there's something I'm overlooking that would do this with less work and code volume?

And if this is my best bet, then is 1 index/ms a good speed to use for extracting sweep offests from the tables? This is kindof a guess... I shouldn't need my sweep response to be faster, but maybe it needs to be slower? The most voice modifiers I'll ever sweep simultaneously on a given beat is 12, with the average being more like 1-2.

firstly, a control rate of 1 index per millisecond does seem excessive. 1 index per 20ms works well for hardware, so that should be fine for pd too. remember you can always use a [line] object to smooth things out at the end anyway.

i can't really see a problem with using batteries of tables. 20 -30 tables per voice should be no problem for pd. i run a sampling looper with 400 tables of audio, and that works fine.

for ease of saving, you might want to read all the arrays you have written into a single [textfile] object, using an identifier number for each array. obviously there will be lots of arrays that are empty, so i suggest that when a sweep is written to an array, you send a value of 1 to the right inlet of a float object. then, when you want to save your arrays to the textfile, first have pd check if the float is 0 or 1 and only write to the textfile if it is 1.

bu the way, do you know about dynamically creating tables? it will save you a lot of time if you need to make hundreds of them.

[pack 0 0 0]
|
[;
pd-subpatch obj 10 $2 table $1-sweepdata $3(

where $1 is the output of a counter (0,1,2,3,4....) , $2 is the y-position of the object you are creating, so just multiply the counter value by 20 to create objects 20 pixels apart , and $3 is the length of the table you want to make.