To mc or not to mc (mc noob-ish questions)
So I finally got around to play with some mc stuff finally as most of what I've had on deck hasn't needed it, and I haven't gone to refactor anything old.
In doing this I've run into a couple of things that seem like simple/obvious problems, but I can't really figure them out.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////
The first one is really simple/stupid. I don't understand how [mc.line~] works in conjunction with 'setvalue'. As in, I want to be able to set the values of individual instances of line, but while still having them be smoothed.
As far as I can tell, you can't send a list with the 'setvalue' message, so it only sends the individual value, and not the ramp time. And loadbanging the right inlet of [mc.line~] doesn't seem to store that info.
So I've had to do this clunky thing where I [t l b] the 'setvalue' message along with a ramp time to [mc.line~]. This seems like a terrible hack.
As a side question to this first question, I wonder if there's a "native" mc way to accomplish the same task, which in this case is turning up/down lots of channels but in a crossfade. So if I have 100channels, I want to gradually fade them all in, starting from 1 and at the end having all 100 channels going.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////
The second question has to do with how "multichannel" audio works in the mc universe. As in, a single buffer that has lots of channels, which I want to play with a single instance of an mc object.
This was the first thing I played with and really threw me, as it seems like I can't have a buffer with 127 channels, and then play all of them using [mc.play~] or [mc.groove~] or whatever. If I '@chans 127' them, they play 127 voices of the first channel of the buffer.
So what I've done is this horribly clunky [play~ 127] -> [mc.pack~ 127].
Is that the way to go about this?
(basically I'm working with a toolbox that creates lots of individual audio files with lots of channels, so being able to use mc on these would save a lot of hassle in terms of dealing with individual channels and/or polys)
Ah nice, [mc.target] sorts that out. (I was looking for a "target" message, but didn't think to try it as an object).
For the second one (your thread is what got me thinking that I should ask on here, as I wasn't the only person confused about that!) I'm trying to just playback a multichannel file, without having to "convert" it to an mc signal path. Or rather, just have the mc object read the different channels of a buffer (rather than creating multiple instances of the first channel). I don't want or need two playback objects, I was just showing how I'm doing it at the moment ([play~] -> [mc.pack~]) whereas I would think it would be possible to do the same thing with just a single [mc.play~] (or [mc.groove~]).
I guess I could do the [mc.target] thing and just "set" each channel of [mc.play~] individually, but even then, I don't know if you can 'set' a specific channel of a buffer (i.e. "set test 1"). Polybuffer makes it possible as you can do it in a single message (i.e. "set test.1"), but the files I have a single multichannel buffers, as opposed to multiple buffers stuffed into a polybuffer.
Basically both bits that I posted are from the same patch/idea, just showing my hacky workarounds. The full context is that I have an audio file that I have decomposed into 127 component layers, and then I am "filtering" the audio by bringing each layer in and out.
for the crossfade idea you might want to look at mc.gradient~ object (or mc.evolve~) .
i wonder if mcs.play~ or mcs.groove~ might be what you are looking for
Man, [mc.gradient~] is just what the doctor ordered!
As are the [mcs] options!
Out of curiosity, how did you find out about all of these and/or how the mcs objects work? (the help file just brings up the mc versions, so I had to guesstimate the arguments it takes to work)
Oh, one last thing which is part of the main patch I'm working on for these.
Is there a native mc way to randomly repatch an mc signal path? (as in, take a 127 channel audio path, and shuffle the order of outputs, so something like [mc.gradient~] would sweep across different channels).
Basically something that can replicate this [thispatcher] funny business:
there is some discussion of mcs in some of the help patches. the last tab for the groove~ object has a small example. for gen~ as well. there is a page in the reference called MC vs MCS Objects. this is an area that certainly needs some more documentation.
Thanks, that's very helpful.
Yeah, it's a bit of a mystery out there. Some objects have dedicated help files, others don't and/or point to just the 'wrapped' object etc...
would the the mcs.matrix~ object work for the shuffling?
You're a godsend! Using [mcs.matrix~] would make it easier as I wouldn't have to deal with [coll] to recall the states I want to disconnect. I can just 'clear' the whole thing.
Man, my patch is going to look super elegant now!
yeah - the mc stuff is proving to be a big win once you get familiar with it.
That's a funky/quirky patch!
Here I am boringly playing back audio and adjusting the gain...
On that note, I got the main bit of the patch slimmed down nicely with [mcs.play~] and [mcs.matrix~], which is fantastic. Thanks for the pointers there @TESTCASE.
I have to say [mc.gradient~] is still confusing me.
So what I'd like to do is to be able to fade from having all the audio files playing, to having none of them playing (or perhaps just 1 file playing). In setting up breakpoints it doesn't seem to allow me to do that kind of shape (short of manually creating a super long and complex series of breakpoints?)
I also thought about dynamically adding more breakpoints and/or modifying the breakpoints as I "sweep" the main signal, but that seems overly complex for what I'm after here.
On a hunch I went and played with [mc.mixdown~] some, to see if the 'pancontrolmodes' were what I'm after, but it doesn't appear to be the case.
Ok, also ran into what appears to be the limits of [mcs.] stuff. So because it's a "single copy" of something, it means the channels are not individually addressable.
So if I wanted to have an [mcs.groove~] object where each channel is playing back at a different speed, I can't. It works fine with [mc.groove~], but that won't read multiple channels of a single file...
In this patch I'm having to do a silly [mc.unpack~] -> [groove~] -> [mc.pack~] thing, which works, but seems to defeat the point of having mc objects in the first place.
So I guess what I'm after is the ability to load files like [mcs] but be able to treat them like [mc].
Another option would be to split the multichannel buffer into individual buffers, then [mc.target] all the instances I want, but that seems super hacky, and would be a pain as I'm working with a toolbox that creates tons of multichannel buffers.
I played with some of that, but it's not the movement I'm looking for. Your patch essentially recreates sending a three breakpoint message to [mc.gradient~] (0. 0. 1., 0.5 0.5, 1. 1. 0.).
So in my case I want phase position 0. to start and end at 1., with phase position 1. starting at 1. and ending at 0. That much is working, the problem is it's kind of a linear interpolation between those points whereas I want to be able to fade everything out going from right to left.
So if it was 10 channels, it would look something like this:
sig~ 1.0 - 1 1 1 1 1 1 1 1 1 1
sig~ 0.9 - 1 1 1 1 1 1 1 1 1 0
sig~ 0.8 - 1 1 1 1 1 1 1 1 0 0
sig~ 0.7 - 1 1 1 1 1 1 1 0 0 0
sig~ 0.6 - 1 1 1 1 1 1 0 0 0 0
sig~ 0.5 - 1 1 1 1 1 0 0 0 0 0
sig~ 0.4 - 1 1 1 1 0 0 0 0 0 0
sig~ 0.3 - 1 1 1 0 0 0 0 0 0 0
sig~ 0.2 - 1 1 0 0 0 0 0 0 0 0
sig~ 0.1 - 1 0 0 0 0 0 0 0 0 0
But obviously with floating point transitions and such.
If it was possible to keep moving the phase argument (past 0.) then that would work, or if it was possible to move a breakpoint (which you can), but via the x position, then it would be possible, but it seems like you can only move the y position and/or phase (what you're doing in your example).
That's what led me to look at [mc.mixdown~] as this seems more like a panning-type thing, but it seems to be focused around moving a single point around all the available channels.
/////////////////////////////////////////////////////////////////////////////////////////////////////////
Yeah the [mc] vs [mcs] seems like a weird oversight, or perhaps what I'm doing is some odd edge case, but you would think that an "actual" multichannel file would work well within the [mc] ecosystem.
I agree, it would be nice if there was a way to 'spill' a multichannel [buffer~] into oodles of [polybuffer~]s or at least be able to [uzi]+set channels to an [mc.groove~], but those feel like hacky workarounds to something that should "just work".
I might email that as a feature request and/or make a separate thread highlighting that.
maybe build the play back in mc.gen?
you might want to look at the mc.evolve~ with the multi range object - not sure i totally get what you are trying to do though.
For the [mc.groove~], as a sort of work around for what you want, you could use a polybuffer~ with 127 buffers. Not the cleanest, but it works.
So I submitted the [mc] vs [mcs] playback problem as a feature request and they responded favorably, so hopefully something will come of that.
In the particular use case I'm working on, I can get similar results by just messing with the audio playing back *after* the playback object (since I was after a weird chorus/modulation-type thing), so I've made something that works for the time being.
Doesn't solve the problem for more complex or varied versions of that idea, but it will hold me over for now. (Patch below)
Still struggling with the [mc.gradient~] thing.
Actually here's a patch that shows the kind of movement I want (pulled from a completely unrelated patch).
Basically I want to control the individual gains of the 127 channels in this manner (fading each one out slowly, until all (or 1) are faded out).
@CODY
That would work, but the file I have is a single file with lots of channels, so it would be whole other step to (programmatically) turn a multichannel buffer to single channel polybuffers.
Ok, here's the patch that I came up with to "chorus" by modulating each channel of a 127 channel buffer independently (sounds pretty cool):
And for thoroughness, here's my present solution ([uzi] -> [mc.line~]) for fading audio out to create a "filtered" sound from a multichannel file:
This last one "works", but each step of the "filter cutoff" knob is binary, and at higher channel counts (e.g. 499 channels), [uzi] starts to hang the scheduler.
