Rodrigo

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.

comment

number

join

jit.cellblock

prepend

mc.line~

pack

flonum

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].

(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)

mc.dac~

mc.mixdown~

toggle

play~

mc.pack~

message

mc.sig~

mc.groove~

buffer~

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////

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.

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

to-mc-or-not-to-mc-mc-noob-ish-questions

For your first question(s), to target specific voices, you wanna check out the 'mc.target' object('setvalue' automagically comes from mc.target(although if you wanted to cobble together your own version of mc.target maybe you could use the message without it), so you can just send the same kinds of messages you'd send a regular line~ object but send it through mc.target)... something like this:

(there's also mc.voiceallocator~ for automatic voice allocation)

your second question is a bit harder to answer as i think i'm confused as to why you'd combine play~ and mc.groove~ in the first place(?)... but i'm guessing you probably ran into a problem like the one we ran into here:

https://cycling74.com/forums/mc-groove~-and-polybuffer~

i think you can, it just takes getting more familiar with how the MC world routes outputs... maybe try all that info. out and if you still have probs with the mc.groove~/play~ stuff, post back again(i'm headed out but will check back to see if i can help further later).

your second question is a bit harder to answer as i think i'm confused as to why you'd combine play~ and mc.groove~ in the first place(?)... but i'm guessing you probably ran into a problem like the one we ran into here:
https://cycling74.com/forums/mc-groove~-and-polybuffer~ 

"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"

i think you can, it just takes getting more familiar with how the MC world routes outputs... maybe try all that info. out and if you still have probs with the mc.groove~/play~ stuff, post back again(i'm headed out but will check back to see if i can help further later).
hope it helps.


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

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!

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.

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?

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.

yeah  - the mc stuff is proving to be a big win once you get familiar with it.

i meant to post earlier(saw that mcs.groove~ is the way to go for playback from one single multi-channel buffer~), but got lost trying out all the stuff TESTCASE mentioned:

(now i have nothing to offer but experimental patch-madness 😋 ...try pushing the frequency (where it says, "slow down...") to higher freqs, too, even around sampling-rate.... i think i made a good patch-poop here 💩 😇)

(now i have nothing to offer but experimental patch-madness  😋 ...try pushing the frequency (where it says, "slow down...") to higher freqs, too, even around sampling-rate.... i think i made a good patch-poop here 💩 😇)

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.

for your gradient question, it might be something like this:

an attempt at an explanation: i think the list for mc.gradient~ can be up to 4 elements, indicating #1: the phase at which everything is applied, #2: the lower range applied, #3: the upper range applied, and #4: a phase offset...... if we leave #2 and #3 the same(this is the same as only using argument #2), we skip giving it a range, and #4 is probably for special cases, so all we need(i think) is arguments #1 and #2 to tell it the values(arg #2) we want at phase(arg #1) 0.(the lowest channel number) and phase 1.(the highest channel number), and mc.gradient~ will shift the gradient between all the channels in-between as we shift the lowest and highest channel between 0.(silence) and 1.(full-loudness).

edit: no wait, i reread your question for mc.gradient~ and you wanted finite control over just one channel(?)... maybe mc.gradient~ isn't the best thing in that case and you probably want to be more specific by using mc.*~... if you are looking for a shifting gradient between the files where they fade out completely you can adjust my message in that patch to sweep differently(now it's sweeping opposite ends between 0 and 1, but you could do the opposite ends of the channel-spectrum in separate messages to make them go gradually to 1, then back to 0 again... hard to explain, but it's possible if you don't need to control amplitude on the channels in-between too specifically)

as for your mc.groove~ question, i think you're right: it's not possible. you can switch the mcs.groove~ in your patch to mc.groove~, then you'll have the individual channels coming out of 4 outlets instead of 1, but they'll still have 4 channels each(3 extra/unneeded channels there in each outlet), and so you'd still have to mc.unpack then mc.pack in a weird way.

if you have a multichannel file but really want individual control over each channel, you probably have to split the channels of the file into separate buffer~s(i wish they designed a special loading message to polybuffer~ so it might do this automatically for us within the buffer~s of polybuffer~(?) then you could easily use that instead..... or if part of the 'set' message to groove~ could include channel number(like "set main 2" to set a single-channel groove~ to the 'main' buffer~, channel '2') then you could also do this type of thing with mc.groove~, but we don't have any options like that)

as for your mc.groove~ question, i think you're right: it's not possible. you can switch the mcs.groove~ in your patch to mc.groove~, then you'll have the individual channels coming out of 4 outlets instead of 1, but they'll still have 4 channels each(3 extra/unneeded channels there in each outlet), and so you'd still have to mc.unpack then mc.pack in a weird way.
if you have a multichannel file but really want individual control over each channel, you probably have to split the channels of the file into separate buffer~s(i wish they designed a special loading message to polybuffer~ so it might do this automatically for us within the buffer~s of polybuffer~(?) then you could easily use that instead..... or if part of the 'set' message to groove~ could include channel number(like "set main 2" to set a single-channel groove~ to the 'main' buffer~, channel '2') then you could also do this type of thing with mc.groove~, but we don't have any options like that)

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:

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.

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

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.

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).

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.

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.


And for thoroughness, here's my present solution ([uzi] -> [mc.line~]) for fading audio out to create a "filtered" sound from a multichannel file:

To mc or not to mc (mc noob-ish questions)