I’m thinking of building a device to automate track sends.
What I have in mind is a device that will, over time, semi-randomly modify the send-level of a group of tracks. I was hoping to use something like LineFO or PeakMod but, so far as I can see, none of these devices offer track sends as a target for their automation data.
So now I’m trying to think about how this could work and, in particular, how to specify the tracks that should be automated.
Has anyone seen any good metaphors for selecting multiple tracks in a M4L device?
I’m unfamiliar with the patches you mentioned, but what’s stopping you from modifying those patches to make them access sends as well? Shouldn’t be too hard I think..
As to selecting multiple tracks; not sure I understand the question here. Are you referring to a GUI which allows the user to select multiple tracks or are you wondering about the technical aspects to process these tracks?
Because that shouldn’t be too hard. A mere umenu object will already allow you to present multiple choices to a user after which he can make a selection of that. After that you can simply process this further by grabbing the track names or ID’s (careful when using id’s only) and use them in your patch.
Those devices would have worked as a very basic first approach to the problem. But, in general, they only automate one or two parameters. What I have in mind involves 16 tracks (at present) with co-ordination between them that would be very hard to organise using multiple copies of the devices.
Given that it seems to make more sense to create the device I want, assuming it’s not too hard.
A umenu, using checkitem, does look like it would work for toggling of enabled/disabled per track, thanks for the suggestion.
But what about if I wanted to be more ambitious with routings affecting multiple tracks. Then I guess I’d be looking at something like a matrixctl but dynamically generated and labelled.
I’ll start with something basic but I’m interested in what others have done in this area.