Implementing [change] on [mc.~] signals. Suggestions and best practices?
Hi all,
Can't find this on the forum so hopefully I'm not duplicating a post.
I’m using [mc.~] for signals that become MIDI CC/UDP/DMX/GUI messages via [snapshot~] or [mc.snapshot~].
The signals are coming from [mc.gen~] in which an incoming LFO signal, expression pedal* or other MIDI controller** sweeps through a buffer channel that’s acting as a lookup table
(* and ** are converted into [sig~]).
Looking for a way to filter out repetitions in the control data, including or akin to [change].
I’ve been messing with a few options which I’ll flesh out below in case useful.
Writing to request advice on which options are best practice.
I’d like to keep it in [mc.~] domain.
Has anyone had any luck achieving this type of goal?
Thanks – Dawes
Adding background info, what I've done so far, what works/what's failed:
Event-driven vs non-event driven:
I’ve tried making the retrieval event-driven by using [mc.change] into [mc.==~ 0] into [mc.edge~] into [zl.reg] into [route voice].
This notifies when a change occurs by sending the voice on which the change occurs.
This in conjunction with [t b I] means you can send a bang to trigger [mc.snapshot~].
Caveat: [mc.snapshot~] outputs all channels which each bang, so it’s impractical in a scenario where only one or very few channels are changing.
Voice resizing:
I’ve tried using an event-driven [snapshot~] which listens to only the relevant voice, using [mc.resize~], [mcs.matrix~] or [mc.selector~].
All three of them have timing issues, it looks like they can’t refocus on new voices quickly enough to keep up with the message commands(?).
Making this event-driven also seems wasteful for scenarios where the majority of channels are changing continuously.
[zl.] list alternative:
Can use [route voice] number to look up the values in a [zl.] list after [mc.snapshot~] into [mc.makelist].
Whether using [mc.snapshot~ 15] or event-driven [mc.snapshot~], it feels wasteful.
I don’t recall encountering timing issues but I have abandoned it.
[table] alternative:
You can also run [mc.snapshot~] into a [table] and use [route voice] number to look up current value.
Works great, and I’m biased toward this over [zl.] list lookups, but it also feels wasteful.
[gen~]+[buffer~] alternative:
Inside of [mc.gen~] I can load current sample into a [buffer~] channel then use [route voice] number to look up value in [peek~].
Works great too, but updating [mc.~] buffer channels 48,000 times per second feels even more wasteful.
I’ve been told [gen~] is ultra lightweight, BUT, I don’t know how updating buffer channels fits into that.
[unjoin]+[change] alternative:
At this point I’m talking myself into just running [mc.snapshot~ 15] into [mc.makelist] then [unjoin].
Each signal hits its own [change] object then [funnel] to bind them back together.
Doesn’t feel wasteful exactly (though I'd certainly encapsulate and probably downsize and copy and paste it), but does feel unnecessary.
What’s should I know in order to choose the most efficient method?
Thanks again.
Have you tried targeting just one instance of mc.snapshot~ from your existing voice events, instead of sending a plain bang? The mc.snapshot~ reference documents the setvalue message for sending a message to one wrapper instance. I haven't tested your patch, so this is a route to check rather than a claim about timing or speed.
...you can use change~ and control a gate~ with it? this replicates what change does for data rate.